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Verf ahren zur Vergebuhrung eines Dienstes ,in einem Kommunika 
tionsnetz 

Problemstellung der Erfindung 

5 

In einem paketorientierten Kommunikationsnetz mit Dienstan- 
wendern (z.B. SIP-Clients) , Diensterbringern (z.B. Applikati 
ons-Servern) und einem vermittelnden Applikationsbroker (z.B 
SIP Proxy) , der fur die Dauer der Servicebeziehung zwischen 

10 einem Client und einem Application Server nicht in diese Be- 
ziehung eingebunden ist, (d.h. z,B. kein Stateful SIP-Proxy) 
ist es fur den Proxy unmoglich eine zuverlassige Vergebiih- 
rungsf unktion fur registrierte Kunden (Anwender und 
Diensteanbieter) bereitzustellen. Aus Garunden der Effizienz 

15 (Hardware- und Betriebskosten) , ist es fur grofie Netzkonfigu 
rationen mit einer Vielzahl von Proxies von Vorteil, wenn ei 
ne Vergebuhrungseinheit mit mehreren Proxies im Netz gleich- 
zeitig zusammenarbeiten kann. 
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Bisherige Losungen der Problemstellung 



Proxy bleibt in der Kommunikationsbeziehung fiir die Dauer 
der Servicebeziehung (Stateful Proxy) , oder 
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Vergebuhrung lauft separat zwischen Application Server und Client 
ohne Einbeziehung des Proxies, d.h. der Betreiber des Proxies ist 
ausschlieSlich Access -Provider . Eine Gesamtrechnung aus einer Hand 
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auch fur in Anspruch genommene Dienste lassen sich - wenn uberhaupt - 
dann nur mit groSem Aufwand im Postprocessing erreichen Verteilte 
Billingfunktionen beim Proxy -Betreiber und beim Application Server 
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Provider; 

Brfordert (a) Sicherstellung, daS der Nutzer eines Services auch 
gleichzeitig Kunde von Proxy- und Serverbetreiber ist, und (b) Uber- 
mittlung von Daten an den zentralen Rechnungsersteller . 
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Losung der Problemstellung gemafe der Erfindung 

Die Erfindung beschreibt ein Verfahren, wie in einem derarti- 
gen Scenario mit Client, Proxy {=Applikationsbroker , Applika- 
tionsvermittlungseinrichtung) , Vergebuhrungseinheit (Billing 
Server) und Applikationsserver eine fur alle Partner zuver- 
lassige Vergebuhrung erreicht werden kann, die zudem fur den 
Anbieter (Provider) des Grunddienstes (Betreiber der Proxies 
und des Billing Server) einen Mehrwertdienst darstellt. Die- 
ser Provider ist damit in der Lage, seinem Endkunden eine zu- 
verlassige Rechnung aus einer Hand mit paketorientierten 
Diensten von unterschiedlichsten Partner -Serviceprovidern an- 
zubieten. Dabei kann der Grunddienstanbieter sowohl als ein- 
facher Vermittler eines Dienstes, als auch als Zwischenhand- 
ler mit „Rebranding^* auftreten (Unter ,,Rebranding^^ wird hier- 
bei verstanden, dass der Betreiber des Proxy einen Dienst ei- 
nes Partner-Serviceprovider nicht unter dem ur sprung lichen 
Namen des Dienstes sondern unter einem eigenen Produktnamen 
anbietet) - 

Letztendlich ist der Zweck dieses Verfahren, 
- a) Registrierten Endkunden (Clients) mit einem Gut habenkon- 
to in Echtzeit Nutzungsgebiihren fiir angeforderte und ge- 
nutzte Dienst e zu verrechnen, oder 
b) Registrierten Endkunden regelmafiig (z.B. monatlich) eine 
einheitliche Gesamtrechnung fur alle genutzten Seirvices 
von unterschiedliclien Providern zu erstellen. 

Mit dem Verfahren wird sicbergestellt , dass 

a) der Kunde nur das bezahlt, was er nutzt, und 

b) der Diensterbringer fur seine Leistungen bezahlt wird. 

Daneben schafft dieses Verfahren die Voraussetzung dafur, 
dass dem Kunden als Option schon wahrend der Dienstenutzung 
in Realzeit angezeigt werden kann, welche Gebuhren fur den 
Dienst aufgelaufen sind, bzw. bei Prepaid-Service, wieviel 
Guthaben noch vorhanden ist. 
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Grundlage dieser Losung ist eine zuverlassige Vergebuhrungs- 
funktion, in die alle Partner-Komponenten (Client, Proxy / 
Application Broker, Application Server) wahrend der Dienste- 
nutzung eingebunden sind. 

Client: Authentif iziert sich bei einem Proxy und fordert 
Dienst an. 

Proxy / Application Broker ; Vermittelt den angef orderten 
Dienst und stoSt die Vergebiihrung auf dem Billing Server an. 
Billing Server ; Fiihrt Buch iiber die Nutzung dieses Dienstes 
durch den Client . 

Application Server : Bietet Dienst an und informiert mit Ti- 
ckets den Proxy liber Zustandekommen und Verlauf der Seinrice- 
beziehung zwischen ihm und dem Client • 

Die weitere Erlauterung der Erfindung wird durch eine Zeich- 
nung unterstutzt, die drei Abbildungen umfasst. 

Abbildung 1 zeigt die Beziehungen der Partner untereinander 
und den prinzipiellen Ablauf von der Authentif izierung des 
Clients liber die Dienstanf orderung und Diensterbringung bis 
hin zur Vergebiihrung. Dieser Ablauf wird im folgenden anhand 
von Abbildung 1 beschrieben^ 

- Nachdem sich der Client mithilfe des Proxy bei dem Authen- 
tif ication -Authorization -Account ing-Searv^er (AAA- Server) 
authentif iziert hat (1) / (2a) , informiert der Proxy den 
Billingserver uber den anstehenden Servicewunsch. Der Bil- 
lingserver verwaltet die Billingtabelle und erzeugt dafur 
auch die Referenzen pi pro Servicewunsch. Diese Referenz 
wird dann an den Proxy zurvickgegeben (2b) . Der Proxy iiber- 
mittelt dann dem Client neben der Angabe, wo sich der Ap- 
plication Server befindet (Destination) und der Billing- 
Reference (pi) auch noch die Adresse des Billingservers 
(3) . Im weiteren Verlauf des Services kommunizieren dann 
Client, Sexver und Billingserver unter AusschluS des Pro- 
xy- 
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- Der Client fordert mit der Information, die er vom Proxy 
erhalten hat, beim Application Seirver den gewunschten 
Dienst an (4) . Dieser bestatigt die Di ens tanforderung an 
den Client (5) . Hiermit ist die Servicebeziehung zwischen 

5 Client und Application Server eingerichtet . 

- Nachdem die Servicebeziehung zwischen Client und Applica- 
tion Server aufgebaut worden ist, und solange der Dienst 
genutzt wird, erstellt der Application Server in regelma- 
Sigen Abstanden Tickets (z.B, 1 pro Minute), die an den 

10 Billing Server gesendet werden (6) . Diese Tickets enthal- 

ten die Reference pi, die dem Billing Server erlaubt, ef- 
fizient auf die Vergebuhrungstabelle (Billing-Tabelle) zu- 
zugreifen, und die Reference si, die der Seirver selbst er- 
stellt hat, und mit welcher er gegebenenf alls spater bei 

15 einer Riickmeldung vom Billing Seirver eff izient auf seine 

Daten zugreifen und eine bestehende Service Relationship 
beenden kann. 

- Nach Erhalt eines Tickets (6) ermittelt der Billing Server 
anhand der in dem Ticket enthaltenen Reference pi den 

20 Client (IP-Adresse CI) und fordert von diesem fur jedes 

empfangene Ticket eine Bestatigung dieser Vergebuhrungsda- 
ten an (7) . Falls nach einer bestimmten Zeit (z.B. 1 Se- 
kunde) die Bestatigtmg nicht empfangen wurde, wird die An- 
forderung (7) ein- oder zweimal wiederholt . 

25 > Nach Empfang der Bestatigungsanf orderung verifiziert der 
Client das Ticket und sendet gegebenenf alls eine Bestati- 
gung an den Billing Server (8) . 

- Nach Empfang einer Bestatigung vom Client speichert der 
Billing Server das Ticket zu einer spateren Rechnungser- 

30 stellung ab (9) und informiert den Application Server, daE 

der Client das Ticket bestatigt hat. Im Falle eines Pre- 
paid-Kianden aktualisiert der Billing Server den Guthabens- 
tand des Kunden, 
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Sonderfalle bei der beschriebenen Realisierungsvariante der 
Erf indung : 
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Prepaid - Kunde : 

Wenn das Guthaben eine bestimmte Schwelle unterschreitet 
informiert der Billing Server den Client, daS das Guthaben 
5 fast aufgebraucht ist. Dies kann z.B. mit der nachsten An- 

forderung einer Bestatigung fur ein Ticket erfolgen (7) . 
Falls das Guthaben aufgebraucht ist, wird der Billing Ser- 
ver den Eintrag in der Billing Table loschen und weitere 
Tickets vom Application Server fur diesen Kunden nicht 
10 mehr akzeptieren xmd diese Tickets dem Application Server 

negativ quittieren, woraufhin dieser die Servicebeziehung 
zum Client gegebenenf alls beenden wird, 

- Anforderung einer Ticketbestatigung (7) vom Client negativ 
15 quittiert: 

Der Billing Server informiert den Application Server, dalS 
ein Ticket negativ quittiert wurde, wobei er dem Applica- 
tion Server die Reference si zuriickgibt. Anhand der Refe- 
rence si ist der Server daraufhin in der Lage, die Servi- 
20 cebeziehung zum Client zu beenden. 

- Ticketbestatigung vom Client trotz mehrmaliger Anforderung 
nicht erhalten: 

Der Billing Server infoirmiert den Application Server, daS 
25 er fur ein Ticket keine Quittung vom Client erhalten konn- 

te, wobei er dem Application Server die Reference si zu- 
ruckgibt. Anhand der Reference si ist der Server daraufhin 
in der Lage, die Servicebeziehung zum Client zu beenden. 

3 0 - Timer tl fur Billing Table Eintrag lauft ab. 

Um die Gultigkeit eines Billig Table Eintrags zu sichern, 
liberwacht der Billing Server den Eingang der Tickets vom 
Application Server. Sobald ein Ticket (6) eintrifft, wird 
der eingestellte Timer zuriickgesetzt . Bei Ablauf des Ti- 

35 mers wird der Eintrag in der Tabelle geloscht. Eventuell 

nachfolgend eintref fende Tickets vom Server werden negativ 
quittiert . 
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Bin Ausschnitt des Meldungsablauf es (1) - (3) , der in Abbil- 
dung 1 dargestellt und bereits beschrieben ist, ist fiir ver- 
schiedene Realisierungsvarianten der Erfindung in Abbildung 2 
dargestellt . 

Realisierunqsvariante 1 : Die in J^bbildung 1 beschriebene Va- 
riante . 

Realisierunqsvariante 2 : Die Variante 2 unterscheidet sich 
von der Variante 1 insofern, dafi der Proxy, nachdem der Bil- 
ling Server von dem Verbindungswunsch informiert wurde, keine 
Billing Reference (pi) mehr vom Proxy erwartet, sondern die 
Antwort auf den Service Request vom Client ohne pi an den 
Client zuriicksendet (3a) . Der Client erwartet stattdessen die 
Billing Reference vom Billing Server und wendet sich mit dem 
Service Request (4) an den Application Server erst dann, wenn 
er die Billing Reference in einer separaten Nachricht (3b) 
erhalten hat . 

Die Korrelation der Information in den Nachrichten 3a) und 
3b) mit dem ursprunglichen Service Request (1) erfolgen fiber 
eine existierende eindeutige Reference (Call id. Tag) , die 
vom Client fiir jeden. Service Request generiert wird und in 
den Nachrichten 2b), 3a) und 3b) enthalten ist. 

Realisierunqsvariante 3 ; Die Variante 3 unterscheidet sich 
von der Variante 2 insofern, daS der Proxy in diesem Fall 
selbst keine Antwort auf den ursprunglichen Service Request 
(1) an den Client sendet . Nachdem der Billing Server vom Pro- 
xy mit alien relevanten Daten versorgt wurde (2b) , generiert 
der Billing Server eine Billing Reference pi und sendet sie 
gemeinsam mit den Daten, die er vom Proxy erhalten hat, als 
Antwort auf den Service Request (1) an den Client. 



Abbildung 3 beschreibt die Einbindung des Billing Seirvers in 
das Kommunikationsnetz als Partner von mehreren Proxies. Sie 
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zeigt eine prinzipielle Anordnung von Clients, Application 
Servers, Proxies und einem zentralen Billing Server. 

Indem die Billingserver gegebenenf alls mit interner Redundanz 
ausgestattet werden und zusatzlich mehrere Billingserver 
gleichzeitig eingesetzt werden konnen, wird diese Realisie- 
rungsvariante hoch verfiigbar und gleichzeitig hoch skalierbar 
(m Billingsearver fur n Proxies und z Application Server, m < 
n) . 

Bemerkungen ; 

_ zu beachten ist, da£ dieses Verfahren nicht erfordert, 

dass Server und/oder Client sich bei Beendigung der Servi- 
cebeziehung beim Billing Server abmelden. So erfolgt auch 
die Versendung eines Vergebuhrungstickets an den Client 
immer im Voraus fur das aktuelle Vergebiihrungs interval 1 . 
Damit ist sichergestellt , dass der Client nicht kosten- 
pflichtige Dienste in Anspruch nimmt, ohne dass er dafiir 
bezahlt, indem er vor Ablauf eines Vergebuhrungsintervalls 
einfach den Dienst abbricht, urn zu verhindern, dass er fur 
das vergangene Intervall vergebuhrt wird. 

- Der Ubeirwachungstimer tl in der Billing Table muss auf je- 
den Fall groEer als die Lange des Vergebiihrungs intervall 
sein, das zwischen Client und Application Server verein- 
bart wird. Es muss grofi genug gewahlt werden, um zu ver- 
meiden, dass eine verloren gegangene (und deshalb vom Ap- 
plication Server wiederholte) Ticketnachricht an den Bil- 
ling Server dazu fuhrt, dass dieser den Billing Table Ein- 
trag fur ungiiltig erklart . Gleichzeitig darf tl aber nicht 
zu groiS gewahlt werden, um zu vermeiden, dass beispiels- 
weise Denial -of -Seirvice Attacken von boswilligen Clients 
zu einer Verknappung der Billing Table Resourcen und 
letztlich zu einer Nichtverf ligbarkeit dieser Dienste 
fuhrt, Ein verniinf tiger Wert fur tl ist 2-3 Mai die Lange 
des Vergebuhrungsintervalls* Da die Lange der Vergebiih- 
rungs inteirvalle der einzelnen Servicebeziehungen (siehe 
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Abb, 1) unterschiedlich sein konnen, wird die Lange des U- 
berwachungs timer tl variabel gestaltet. Sobald der Billing 

— , ^ • „ rr»j _l . ^ — ^ TV T -I ^ 4- -I .^v-» G <=» -v~-t r<:i-K- /(=i-K*"K 1 tris*T-TA70"nr1o f- 

er die darin angegebene Lange des Vergebuhrungsintervall 
und besti^mmt daraus die Lange von tl, urn den Empfang des 
nachsten Tickets vom Application Server fur diese Service - 
beziehung zu iiberwachen. Bis zum Empfang des ersten Ti- 
ckets vom Application Server wird ein fur die Billing 
Table einheitlicher fester Initialwert fur diesen Timer 
verwendet (z*B. 5 Sekunden) • 

Mogliche vertrauensbildende MaSnahmen zwischen Client und 
Application Server; Die Konditionen fur die Seirvicebezie- 
hung (Lange und Kosten des.l. Intervals, Lange und Kosten 
der Folgeintearvalle) werden zwischen Client und Server 
vereinbart. Durch die Wahl eines kurzen 1. Intervalls und 
ggf , Sonderkonditionen dafur kann sichergestellt werden, 
daS auch im Falle einer Nichterbringung der Leistung (z*B. 
Serverausfall, Uberlast, SW-Fehler, Inkompatibilitat von 
Client und Serversof tware) trotz aufgebauter Servicebezie- 
hung fur den Dienstanwender kein oder nur ein geringer 

Nachteil entsteht 
. Bei Ausfall des Billing Servers kann ..der Application Ser-- 
ver aufgrund der ausbleibenden Quittung auf das Ticket die 
Servicebeziehxing zum Client gegebenenf alls abbrechen. 
Bei Ausfall des Clients wird das Gebuhrenkonto des Kunden 
nicht falschlicherweise weiter vom Billing Server be- 
lastet, da Client nicht mehr in der Lage ist, weitere Ti- 
cketbestatigungsanforderungen des Billing Servers zu quit- 
tieren (siehe Sonderfalle) . 

- Funktionalitat beim Client erweiterbar z.B. urn 
i. Kumulierung der vom Billing Seirver ubermittelten Gebuh- 

rennachrichten und Anzeige dieser Gebiihren am Terminal 

zur Gebuhrenuberwachung in Realzeit. 
Li. Moglichkeit fur Endbenutzer als Option Tickets manuell 

zuriickzuweisen, z*B. bei Erreichen eines bestimmten 

selbstgesetzten Gebuhrenlimits. 
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Zusatnmenfassend kann folgendes gesagt warden. Das beschriebe- 
ne Verfahren erlaubt dem Betreiber eines Stateless Proxy bzw. 
Application Brokers auf einfache Art und Weise mittels eines 
Billing Servers registrierten Application Service Anbietern 
5 und registrierten Kunden eine zuverlassige, in def inierbaren 
Intervallen genaue und vertrauenswurdige Vergebuhrungsf unkti- 
on anzubieten, indem sich wahrend der Diensterbringung Client 
und Server standig im Hintergrund in regelmaSigen Abstanden 
liber einen unabhangigen Dritten (Billing Server) liber die da- 
10 fur anfallenden Gebuhren verstandigen und die Vergebiihrungs- 
funktion auch von dem unabhangigen Dritten erbracht wird, wo- 
bei die Vergebuhrungsfunktion auf dem Billing Server insbe- 
sondere fur mehrere Proxies gleichzeitig erbracht werden 
kann. 

/ 15 

Anwendungsbeispiele 

- Auskunf tsdienste 

- Videodienste 

20 - Telef onzusatzdienste, wie z.B. Konferenzen liber Konferenz- 
server 

- Mailboxabf ragen 

- anonymes Billing fur Gateways, die aus dem offenen Internet 
ange s t euer t werden 
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Pat ent anspriiche J. 

* 

1. Billingeinrichtung in einem Kommunikationsnetz, die 

a) eine von einem Client initiierte Dienstanf orderung von ei- 
5 ner Dienstvermittlungseinrichtung empfangt, 

b) fur den Client bezuglich der Dienstanf orderung eine Bil- 
ling-Reference erzeugt, die der Client in einer nachfol- 
genden Dienstanf orderung gegenuber einem Application Ser- 
ver angeben mulS, 

10 c) von dem genannten Application Server erstellte Vergebuh- 
rung-Tickets empfangt, wobei die Tickets Inf ormationen 
hinsichtich der vor bzw. wahrend der Dienstnutzung fur ei- 
nen Dienstnutzer fallig werdenden Gebuhren enthalten, 

d) bezuglich eines vom Application Server empf angenen Tickets 
15 jeweils eine Best at igungsanf rage an den Client des Dienst- 

nutzers richtet, 

e) fiir das Ticket eine Gebuhrenregistrierungsaktion durch- 
fiihrt, falls sie von dem Client eine Bestatigung fur das 
genannte Ticket empfangt. 

20 

2. Billingeinrichtung nach Anspruch 1, 
dadurch gekennzeichnet , 

dass sie die genannte Billing-Reference an die genannte 
Dienstvermittlungseinrichtung sendet, die die Information 
25 dann dem Client mitteilt- 

3. Billingeinrichtung nach Anspruch 1, 
dadurch gekennzeichnet, 

dass sie die fiir einen Client erzeugte Billing -Reference dem 
3 0 Client direkt zusendet. 



4. Billingeinrichtung nach einem der Anspruche 1 bis 3, 
dadurch gekennzeichnet, 

dass die genannte Gebuhrenregistrierungsaktion fur einen Pre- 
35 paid-Client und einen Rechnungs- Client gleichermafien durch- 
fxihrt . 
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5, Billingeinrichtung nach einem der Anspruche 1 bis 4, 
dadurch gekennzeichnet , 

_3 — ^AM«^*-.^4>^ r^^si-vVWi -v-icar^ -J ^ -t— -v- -i i*-»/-to=»1^'H t r^r-i H v* n V^ci of- <=iV-i -K 

dass sie das Ticket zu einer spateren Rechungserstellung ab- 
5 speichert . 

6* Billingeinrichtung nach einetn der Anspruche 1 bis 5, 
dadurch gekennzeichnet, 

dass die genannte Gebuhrenregistrierungsaktion darin besteht, 
10 dass sie den Guthabenstand oder Gebiihrenstand des Client ak- 
tualisiert • 

7- Billingeinrichtung nach Anspruch 6, 
dadurch gekennzeichnet, 
15 dass 

sie den Client informiert, falls der Guthabenstand eine be- 
stimmte Schwelle erreicht bzw. unterschreitet , 
a) sie den Application Server informiert, falls kein ausrei- 
chendes Guthaben mehr vorhanden ist. 

20 

8. Billingeinrichtung nach einem der Anspruche 1 bis 7 
dadurch gekennzeichnet , _ 

dass sie dem Client die fiir die Gebuhrenregistrierungsaktion 
herangezogene Gebiihr mitteilt^ 

25 

9. Billingeinrichtung nach einem der Anspruche 1 bis 8 
dadurch gekennzeichnet, 

dass sie Dienstanf orderungen von einer oder mehreren Dienst- 
vermitt lungs einrichtungen empfangt und bearbeitet. 

30 

10. Application Server, der 

a) von einem Client eine Dienstanf orderung empfangt, wobei 
die Dienstanf ordemng eine Reference auf eine Billingein- 
richtung enthalt, 
35 b) bezuglich des Dienstes Vergebuhrungs -Tickets erstellt und 
diese an die Billingeinrichtung sendet, wenn er den Servi- 
ce-Request annimmt, wobei die Tickets Inf ormationen hin- 



11 



200319344 



sichtich der vor bzw. wahrend der Durchfiihrung des Diens- 
tes fur den Client fallig werdenden Gebuhren enthalten, 
c) von der Billingeinrichtung Mitteilungen dariiber empfangt, 
ob die Tickets durch den Client bestatigt werden, 
5 d) die Durchfiihrung des Dienstes auf rechterhalt ^ solange die 
Tickets durch den Client positiv bestatigt werden. 

11. Application Server nach Anspruch 10, 
dadurch gekennzeichnet , 
10 dass er die Servicebeziehung zum Client beendet, wenn er von 
der Billingeinrichtung die Mitteilung empfangt, daE der 
Client eine Bestatigungsanf rage beziiglich eines Tickets nega 
tiv quittiert hat, 

15 12. Application Server nach Anspruch 10, 
dadurch gekennzeichnet, 

dass er die Servicebeziehung zum Client beendet, wenn er von 
der Billingeinrichtung die Mitteilung empfangt, dafi der 
Client eine Bestatigungsanf rage bzw. mehrere Bestatigungsan- 
20 fragen bezuglich eines Tickets liberhaupt nicht quittiert hat 

13. Application Server nach Anspruch 10, 
dadurch gekennzeichnet, 

dass er die Servicebeziehung zum Client beendet, wenn er von 
25 der Billingeinrichtung liberhaupt keine Quittung auf das von 
ihm generierte Ticket erhalt . 

14. Application Server nach Anspruch 10, 
dadurch gekennzeichnet , 

3 0 dass er die Servicebeziehung zum Client beendet, wenn er von 
der Billingeinrichtung im Falle eines Prepaid-Nutzers beziig- 
lich eines Tickets die Mitteilung erhalt, daS kein ausrei- 
chendes Guthaben mehr vorhanden ist. 

35 15. Client, der 

a) an eine Dienstvermittlungseinrichtung eine Dienstanf orde- 
rung stellt, 
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b) nach einer erf olgreichen Authentif izierung der Dienstan- 
forderiing eine Reference auf den angef orderten Dienst emp- 
f angt , 

c) anhand der genannten Reference eine Servicebeziehtmg zu 
einetn Application Server des angef orderten Dienstes auf- 

baut / 

d) von einer Billingeinrichtung Bestatigungsanf ragen uber 
hinsichtlich des Dienstes fallig werdende Gebvihren emp- 
f angt , 

e) die genannten Bestatigxingsanf ragen gegenuber der Billin- 
geinrichtiHig verifiziert und beanwortet. 

16. Client nach. Anspruch 15, 
dadurch gekennzeichnet , 

dass er die von der Billingeinrichtung mithilfe der Bestati- 
gungsanf ragen ubermittelten Gebuhrennachrichten kumuliert und 
diese Gebuhren dem Endnutzer zur Gebuhrenviberwachung in Real- 
zeit anzeigt . 

17. Verfahren zur Vergebiihrung eines Dienstes in einem Kommu- 
nikationsnetz, demgemaS 

a) von einem Client an eine. Dienstvermittlungseinrichtung ei- 
ne Dienstanforderung gestellt wird, 

b) daraufhin mithilfe der Dienstvermittlungseinrichtung eine 
Authentifizienang des Clients durchgefuhrt wird, 

c) nach einer erfolgreichen Authentif izierung durch die 
Dienstvermittlungseinrichtung einer Billingeinrichtung die 
Dienstanforderung mitgeteilt wird, 

d) von der Billingeinrichtung fur die Dienstanforderung eine 
Billing-Reference erzeugt wird, 

e) dem Client eine Reference auf die genannte Billing- 
Reference und eine Reference auf die Billingeinrichtung 

mitgeteilt wird, 

f) von dem Client anhand der genannten Dienst -Reference eine 
Servicebeziehung zu einem Application Server des angefor- 
derten Dienstes aufgebaut wird und dem Application Server 
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die Billing-Reference sowie die Reference auf die Billin- 
geinrichtung mitgeteilt wird, 

g) von dem Application Server Tickets erst ell t und an die 
Billingeinrichtung gesendet werden, wobei die Tickets In- 
formationen hinsichtich der vor bzw. w^hrend der Dienst- 
nutzung anfallenden Gebiihren enthalten, 

h) von der Billingeinrichtung bezuglich eines Tickets jeweils 
eine Bestatigungsanf rage an den Client gerichtet wird, 

i) das Ticket von der Billingeinrichtung zu einer Gebiihrenre- 
gistrierungsaktion herangezogen wird, falls das Ticket 
bestatigt wird. 

18. Verfahren nach Anspruch 17, 

dadurch gekennzeichnet , 

dass 

a) das Ergebnis der genannten Bestatigungsanf rage von der 
Billingeinrichtung an den Application Server weitergelei- 
tet wird, 

b) die Durchfuhrung des Dienstes seitens des Application Ser- 
vers aufrechterhalten wird, solange die Tickets durch den 
Client posit iv bestatigt werden. 
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Zusammenf assung : 

Verfahren zur Vergebiihrung eines Dienstes in einem Kommunika- 
tionsnetz 

5 

Das beschriebene Verfahren erlaubt dem Betreiber eines State- 
less Proxy bzw. Application Brokers auf einfaciie Art und Wei- 
se registrierten Application Service Anbietern lind regis t- 
rierten Kunden eine zuverlassige, in def inierbaren Interval - 

10 len genaue und vertrauenswurdige Vergebiihrungsf unktion anzu- 
bieten, indem sich wahrend der Diensterbringung Client und 
Server standig ira Hintergrund in regelmaSigen Abstanden iiber 
einen unabhangigen Dritten (Billing Server) uber die dafur 
anfallenden Gebuhren verstandigen und die Vergebuhriongsf unk- 

15 tion auch von dem unabhangigen Dritten erbracht wird. 

Figur 1 
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